IBIS Macromodel Task Group Meeting date: 26 April 2011 Members (asterisk for those attending): Agilent: * Fangyi Rao Radek Biernacki Ansoft: Chris Herrick Danil Kirsanov Ansys: Samuel Mertens * Dan Dvorscak Deepak Ramaswamy Jianhua Gu * Curtis Clark Arrow Electronics: * Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: * Mike LaBonte Stephen Scearce Ashwin Vasudevan Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: * Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Vladimir Dmitriev-Zdorov Zhen Mu * Arpad Muranyi Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: * Walter Katz Mike Steinberger * Todd Westerhoff Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad update Out-InOut BIRD and send to Mike for posting - Done - Bob update syntax clarification BIRD - In progress - Ambrish start a BIRD on task list row 25 - In progress, on hold - Bob write a BIRD on correcting Table 1-3 in the spec. (Row 23). - In progress, on hold ------------- New Discussion: Arpad showed the Out-InOut BIRD draft: - Arpad: We may be able to vote on this today - Red, blue, and green colors are used to mark different changes made - Walter: SiSoft will vote no - We strongly recommend against it - The Jitter BIRD only uses Model_Specific Out/InOut for TX DCD - We can discuss it then - Sigrity back channel models use it - This would prevent them from using that model - This prevents innovation - Back channel has to use parameters that are not reserved - Arpad: This does not prohibit any feature - It only makes them non-compliant - New BIRDs can be approved when they appear - Todd: "Model_specific parameters ... must not be used" sounds prohibitive. - Agree with Walter - If all loopholes are to be closed then side files would be prohibited too - Ken: Back channel is not totally precluded by this BIRD - Walter: Why does the specification have to preclude this? - Arpad: This only says it is not spec compliant - Todd: It will not be obvious to everyone what is compliant and what isn't - We want to promote standardization and enable innovation in a controlled way - This says if models innovate they are not compliant - The alternative is to not use IBIS - Arpad: A BIRD can be written for any innovation - Walter: Why not say model makers are encouraged to write BIRDs? - Todd: Using straight IBIS 5.0 is no risk - Using BIRDs slated for IBIS 5.1 would be low risk - Prototypes would have higher risk - Vendors should at least be recognized instead of criticized for innovating - At least there would be some continuity in how the change is made - Walter: We should table this to next week - Arpad: This has been discussed for weeks - We should vote - The final decision would be for the Open Forum anyway - Ken: Tools would have to be in reactive mode if innovation is outside of IBIS - We have to get things in the spec faster - There is no efficient way to code for Model_specific parameters - Walter: Are we trying to solve a problem that doesn't exist? - Has any model caused anyone to change their code for Out/InOut params? - Arpad: It would be required to make the model work - The BIRD process is quick enough - Walter: IBM and SiSoft presented at a summit 2.5 years ago about using Touchstone for analog models - This was needed to get the job done for a customer - The innovation was published over a year ago and in BIRDs 119-124 - Arpad: Analog models can't be understood from Opal - That used Info parameters in a non-standard way - Todd: This BIRD is about Out/InOut, not Info - John: It's a 2 way street - SiSoft has benefited from the standard - This has been a constructive process - Todd: We have been committed to this standardization - Ambrish: How can you tell it prevents innovation? - Todd: It says models using this would not be compliant - Ambrish: They would only be non-compliant - Todd: That fact would be used against us by our competitors - Arpad: We should develop a legitimate mechanism now - I am opposed to having a spec that allows meaningless functionality - Todd: We could have had a registry convention to turn these into reserved parameters - Model_specific was because we had no way - Walter: IBIS 5.0 still does not handle diff analog models properly - We should eliminate the need for these things by eliminating IBIS deficiencies - Arpad: Reducing innovation is not the goal - Todd: It is only the by product - We need a controlled way to innovate - Arpad: Fixing innovation would be the next step - Walter: We should not move forward until we understand how to fix innovation - Ambrish: I don't see a problem with this paragraph - Ken: It would only be non-compliant - You can't expect tools to code for anything we add in - We should not need a slew of new params for every innovation - Back channel should be implemented wit a minimum of new things - John: This could cause problems like IBIS 5.0 AMI did - Mike: This BIRD could be submitted without committee recommendation - Arpad: I had started a BIRD with Info - Walter beat me to it - The tool does not know what to do with this - Todd: We need to solve innovation - Fangyi: If the tool uses this to change simulation we have no standard - Walter: Motion to table until we deal with innovation (the motion was not seconded) - Todd: Should my parameters be undeclared and proprietary? - Ambrish: Walter said one model already does this - Todd: My work on jitter etc. would be outlawed - There would be no way for me to innovate - Fangyi: The standard supports innovation - You can create non-standard models first - Todd: Using Touchstone is a good innovation example - Ken: You only need IBIS 5 for that - Walter: How can IBIS 5.0 do that? - Arpad: ICM has it - Walter: That allows only Berkeley SPICE - Arpad: It would have been possible to use an ICM model for a package any time - Michael M.: We have only a few minutes left - What do we need to decide? - Ken: Whether to vote - Maybe we need a new place for experimental keywords - Walter: Let's call it a registered parameter - John: Adoption is not automatic just because things are registered - Arpad: No Model_specific parameter has a description - The spec is wrong - SiSoft says this BIRD will short circuit innovation - Todd: Innovation would be limited to IBIS releases - Arpad: We should find a way to fix that - AMS was supposed to get us away from keywords - Todd: The contract between model and simulator is fixed - Fangyi: We are trying to avoid Opal becoming the standard - Michael M.: Maybe an offline poll of vendors would help here - Walter: IC vendors are not represented here - Arpad: It would have a better audience in the Open Forum - Michael M.: Anyone objecting can suggest alternatives - Arpad: Walter did, but his name is removed from the BIRD now ------------- Next meeting: 03 May 2011 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives